home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
FishMarket 1.0
/
FishMarket v1.0.iso
/
fishies
/
051-075
/
disk_075
/
speeddir
/
poster2
< prev
next >
Wrap
Text File
|
1992-05-06
|
5KB
|
121 lines
Article 4593 of comp.sys.amiga:
Path: mcdsun!noao!hao!ames!ucbcad!ucbvax!COGSCI.BERKELEY.EDU!bryce
From: bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt)
Newsgroups: comp.sys.amiga
Subject: Re: Faster directories under AmigaDOS
Summary: Duplicate efforts -> you are not alone
Message-ID: <8705131021.AA17984@cogsci.berkeley.edu>
Date: 13 May 87 10:21:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: na
Lines: 106
>
> Shit.
>
> It seems like every time I come up with something resembling a useful
> utility, someone else beats me to it, and comes out with something almost
> the same.
>
> Now it's happened again. I *WAS* going to write a program for
> publication in Amazing Computing that did faster directories. Then I found
> out that Dave Haynie has been working on almost the exact same program for
> the exact same magazine. No problem, thinks I, I'll just clean it up a bit
> and throw it at the Net, or RoboCity News, or something.
>
> Now I log in to find this gentleman has already posted a program to
> help speed up directories. It's enough to make a guy beat his head against
> the keyboard. In fact, I think I will.
>
Was that your head or mine? :-)
Well you are not alone. Here's my list:
**
I wrote a icon merger, sent it off to a AmigaWorld (they like simple things
like that). Then comes V1.2. Yup an icon merger.
**
I wrote something on the lines of MORE. I started this AFTER V1.2 was
out, but BEFORE I got V1.2. (March 78. Circumstances saw to it that Developers
got upgraded from Gamma 1 to Release last)
**
A friend spent months working on figuring out how to open windows and create
menu strips. Then out came 'power windows'.
**
I had just finished this neat hack and was going to post it for the entire
net to see. I called it "TrackDiskMon". I dialed up and read the few
messages on the net. You guessed it! TDEBUG had been posted not an hour
before. -> And who wrote that? <- Matt Dillon who lives just up the
street.
----> To add injury to insult HIS WAS BETTER! hmmph. <---
Well that kicked me in the right place and I dragged out some code I wrote
a long time ago when I proposed that C-A put a certain change in V1.2.
That change? Sort by track, not hash. The program? speeddir.
> Oh well, you may as well have the program to see what I did. It
> uses the AmigaDOG ACTION_GET_BLOCK packet to get raw disk blocks off the
> disk and do things to them.
Speeddir was a demonstration program, unfinished. It also works in a
different way. It patches the pr_PktWait field and intercepted any
ACTION_EXAMINE_NEXT packets. It did not re-call DOS with a GET_BLOCK
but rather called trackdisk.device. The difference is that any directory
list program is faster.
> A couple of questions/comments for Bryce and Leo:
>
> On Bryce's "speeddir":
>
> As you pointed out, the drive motor for df1: does not turn off after
> doing a "dir". It *does* turn off though after doing a "copy dfd1:foo ram:",
> or similar command. Is it any "file system write" that deselects the drive,
> or what?
The actual DOS filesystem gets a "ACTION_TIMER" packet every so often. It
uses this to tell the trackdisk.device to turn off after several seconds.
Speeddir and DOS don't really talk to each other. Speeddir is actually
a parisite and as such can't really tell if it is safe to turn the drive
off without upsetting DOS.
What *could* be done is to twoggle some bits or belch some packet
that lets the DOS filehandler
know that it should get around to turning the drive off soon.
----> This and how to access cached buffer are mysteries me <---
> Also, it is interesting that after installing speeddir, the little power
> LED (not the drive LED) blinks alot when doing a "dir", or "copy" command.
> Any idea what is causing that to happen? (BTW, this is using the Manx
> "ls" command for "dir", and the built-in "copy" command of shell v2.05M.)
Gee, I hope so.
I said "HACKERS ONLY" and other expletives like "UNFINISHED". What you
are seeing is my handy-dandy all-purpose BLINK macro. I just sprinkle
a few BLINKS's in all my code and I know when it executes past that point.
Here's BLINK:
blink MACRO ;XOR the power LED
move.l d7,-(a7)
move.b $bfe001,d7
eori.b #2,d7
move.b d7,$bfe001
move.l (a7)+,d7
ENDM
This code is also significant because it was the SECOND thing I ever wrote
in 68000 or on the Amiga. The FIRST was a RTS. (both worked fine
once I got ignored the mess of $%@!* that was passed off as assembler
documentation and hacked it out alone)
On BLINK per directory entry, just after it returns the packet. It was
left in to remind people that the code is unfinished, buggy, experimental,
etc.
-bryce-